Summary

Draft for #707 — adds an Expo Config Plugin (withRockAutolinking) to @rock-js/plugin-expo-config-plugins that re-applies Rock's autolinking patches on every expo prebuild, so they survive Expo CNG regenerating ios/ + android/ from scratch.

User wires it once into app.config.ts:

export default {
  // …
  plugins: [
    '@rock-js/plugin-expo-config-plugins/withRockAutolinking',
    // …
  ],
};

After that, pnpm clear:prebuild (or any expo prebuild --clean) leaves a Podfile / project.pbxproj / Gradle files that Rock can drive — no manual npm create rock re-run after every prebuild.

What it patches

Each transform mirrors the one-shot transform in packages/create-app/src/lib/utils/initInExistingProject.ts:

Each step is idempotent: repeated prebuilds converge on the same file. Already-patched content is detected and short-circuited.

Structure

• packages/plugin-expo-config-plugins/src/lib/config-plugin/withRockAutolinking.ts
  • Four pure string-in/string-out helpers (patchPodfile, patchXcodeProject, patchAndroidBuildGradle, patchAndroidSettingsGradle)
  • Three withDangerousMod wrappers (withRockIosPodfile, withRockIosXcode, withRockAndroid)
  • Top-level composed ConfigPlugin exported as default + named withRockAutolinking
• packages/plugin-expo-config-plugins/src/index.ts — re-exports withRockAutolinking + the patch helpers
• packages/plugin-expo-config-plugins/src/lib/config-plugin/__tests__/withRockAutolinking.test.ts — 13 unit tests

Tests

 ✓ src/lib/config-plugin/__tests__/withRockAutolinking.test.ts (13 tests) 2ms

 Test Files  1 passed (1)
      Tests  13 passed (13)

Each helper covered for:

• Community-CLI input (bare use_native_modules!, default shellScript, default cliFile, default autolinkLibrariesFromCommand)
• Expo prebuild input where the call already has an argument (use_native_modules!(config_command), variable-substituted cliFile, etc.)
• Idempotency (already-patched input → no-op)
• Unrelated content stays untouched

Status: draft

Marking as draft because:

1. patchXcodeProject is brittle. It matches the build phase shellScript with two literal Xcode-emitted strings. RN versions other than 0.83 and the latest Community-CLI default will silently miss. Either: extend the source set as users hit it, or rewrite to parse pbxproj (e.g. via @expo/config-plugins' IOSConfig.XcodeUtils). I'd appreciate a steer on which direction the project wants.
2. Android settings.gradle fallback may over-match. autolinkLibrariesFromCommand could appear inside multiple extensions.configure blocks in unusual setups. The full-block pattern catches the common Expo-generated shape; the fallback regex replaces every occurrence. Wider real-world testing needed.
3. No e2e / integration test against a fresh expo prebuild output yet — only unit tests against representative snippets. Once I have CI access to a Rock dev environment I can wire one up; happy to add it if there's an obvious harness already in the repo I missed.
4. No README / docs update in packages/plugin-expo-config-plugins/README.md yet — wanted maintainer sign-off on plugin name + import path before I write user-facing docs.

Happy to take any of those further (e.g. switch to a pbxproj parser, scope the Android regex, add docs) before this gets merged.

Related

• Issue: Expo CNG support: config plugin that patches Podfile/Gradle on every prebuild #707
• Sibling PR: fix(create-app): preserve existing arg list when patching Podfile #703 (regex bug in the one-shot updatePodfile migrator). The two fixes are independent — fix(create-app): preserve existing arg list when patching Podfile #703 helps Community-CLI projects on the migration boundary; this one keeps Expo CNG projects working long-term.